Context

This is mostly to help #660 by updating DepotDownloader to the latest version and reorganize the installation script. I couldn't recreate the issue on my own ARM64 machine so I'm not sure if this would solve it. I'm hoping it has something to do with this change in the latest version:

Do not abort downloading if one depot fails to get depot key

At this point, DepotDownloader is our only option for Apple CPUs (and probably other ARM64 processors) to download the server files. Refactoring the script to integrate it with steamcmd even if it's not explicitly enabled will probably be a net positive for the user experience.

Choices

• Force ARM64 hosts without 4k page size to use DepotDownloader because steamcmd will never work on them anyways.
• Always fallback to DepotDownloader for all steamcmd commands that fail (non-exit code 0). I don't think there's any disadvantage to doing this at all.
• Check PalServer.sh existence before creation of PalServer-arm64.sh to prevent "non user-friendly" errors returned by the cp, sed, and chmod commands. This is just purely for better experience and log flow.
• I also added -NumberOfWorkerThreadsServer=$(nproc --all) while I'm at it as suggested in Orange Pi 5 Max Performance improvement #640 since it's a pretty small change for an entirely new PR.

Test instructions

1. Ran the container in both architectures without the /palworld folder
2. Ran the container in both architectures with the /palworld folder

Checklist before requesting a review

• I have performed a self-review/test of my code
• I've added documentation about this change to the docs.
• I've not introduced breaking changes.
• My changes do not violate linting rules.